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5 This application claims priority to Japanese Patent 

Application No. JP 2000-357208 filed in November 24, 2000, the 
disclosure of such application being herein incorporated by 
reference to the extent permitted by law. 

J - 10 BACKGROUND OF THE INVENTION 

■1. Field of the Invention 

The present invention relates to a data processing 
% ^apparatus and a data processing method for dealing with an 
5 incidental interruption of power supply in a system. 
% 15 2. Description of Related Art 

m Conventionally, if an incidental interruption of power 

y supply occurs in a system controlled by a computer, recovering 
r has been done either by restarting from a completely initial stage 
f* or by hibernation, in which contents of the memory during 
20 operation before the interruption (or, blackout) are read out and 
*j execution of operations are resumed. 

5 However, restarting presents a problem that carrying out 

all processes, such as detection of devices, initialization and the 
like typically required long time to perform. On the other hand, 

25 in the case of the hibernation, memory information is written out 
irrespective of a program under execution and amount of busy 
memory, thus causing a problem that it took long time to store 
the memory condition as data as well as to recovering it. 
Moreover, hibernation has a problem that it cannot be executed 

30 in the background during processing and it cannot cope with the 
incidental interruption of power supply. 

Conversely, as a method of coping with the incidental 
interruption of power supply such as a sudden blackout or the 
like, there is a method of detecting a low voltage condition and 

35 then instructing an application to end processing. However, 
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such method requires a circuit for detecting the voltage status 
condition. Thus, such method has a problem in which even if 
the circuit for detecting the voltage condition is installed, a 
system software program cannot assure whether all data can be 
5 stored in time until the interruption of power supply after the 
generation of the low voltage condition. * 

However, as this method having been used as a measure 
against power supply interruption, so that for a case of 
recovering the system, this method is carried out perfectly 
10 similarly to restarting or rebooting. Hence, this has a problem 
that it takes a long time for recovering to an operable condition. 
Therefore, the present invention has been conceived so as 
O to provide a data processing apparatus and a data processing 
'2 method, in which, even if an incidental interruption of power 
fil5 supply occurs in a system, it can immediately return back to a 
^ status immediately before the interruption of power supply. 

3 SUMMARY OF THE INVENTION 

ju A first preferred embodiment of the present invention 

f*20 includes a data processing apparatus provided with a central 
In processing unit and a memory including a driver controlling an 
O operation for writing to and reading from a recording medium, 
rT . wherein when there is a request for a status-storing process from 
a component, a dependency relation of the component and/or 
25 stored data is stored as a snap shot file in the recording medium, 
and when there is a request for a status recovering process, a 
status of the component is recovered in accordance with the snap 
shot file stored in the recording medium. 

A second preferred embodiment of the present invention 
30 provides a data processing method including a central processing 
unit and a memory, wherein an operation for writing to and 
reading from a recording medium is controlled by a driver, and 
when there is a request for a status-storing process from a 
component, a dependency relation of the component and/or 
35 stored data are stored as a snap shot file in the recording medium, 
and when there is a request for a status recovering process, a 
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status of the component is recovered in accordance with the snap 
shot file stored in the recording medium. 

When the status-storing process is outputted from the 
component, the dependency relation of the component and/or the 
5 stored data are recorded as the snap shot file in the recording 
medium. In the case of the occurrence of power* supply 
interruption, the status recovery of the component is carried out 
from the snap shot file recorded in the recording medium, in 
accordance with the dependency relation of the component. 

10 A third preferred embodiment of the invention provides a 

computer program for performing the steps of the data 
processing method of the second embodiment. Also, another 
embodiment describes a storage medium storing a software 
program in computer-readable form, in which the software 

15 program enables a computer to perform the steps of the data 
processing method of the second embodiment. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The above and other objects, features and advantages of 
20 the present invention will become more apparent from the 
following description of the presently preferred exemplary 
embodiments of the invention taken in conjunction with the 
accompanying drawings, in which: 

Fig. 1 is a block diagram showing a system to which the 
25 present invention can be applied; 

Fig 2 is a flowchart describing an example of an 
initialization of a component according to a preferred 
embodiment of the present invention; 

Fig. 3 is a schematic diagram describing a relation 
30 between modules for a system status-storing process according 
to a preferred embodiment of the present invention; 

Figs. 4A and 4B are examples of formats of a snap shot 
file according to a preferred embodiment of the present 
invention; 

35 Fig. 5 is a flowchart describing an example of a 

status-storing process according to a preferred embodiment of 
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the present invention; 

Fig. 6 is a schematic diagram describing a relation 
between modules for a system status recovering process 
according to another preferred embodiment of the present 
5 invention; and 

Fig. 7 is a flowchart describing an example of a status 
recovering process according to a preferred embodiment of the 
present invention. 

/ 10. DETAILED DESCRIPTION OF THE PREFERRED 

EMBODIMENTS 
An embodiment of the present invention will be described 
Q ^ below with reference to the drawings. By the way, the same 
L B reference symbols are given to those having the same functions 
m 15 in the respective drawings, in order to avoid duplication of 
5 explanation. Fig. 1 shows a schematic block diagram of an 

m embodiment of a system to which the present invention is 

Q applied. A system shown in Fig. 1 is provided with a CPU 

(Central Processing Unit) 1, a RAM (Random Access Memory) 2, 
20 a device 3, a non-volatile memory 4 and a bus 5. 
! Q The RAM 2 is a memory on which writing/reading 

O operation can be freely performed. The device 3 is, for 
example, a serial device, a graphic device or the like. The 
non-volatile memory 4 is a non-volatile memory device, such as 
25 a flash ROM, a disc or the like. Also, the non-volatile memory 
4 may be a detachable device (media), such as a flash memory 
card or the like, namely, a so-called IC card. The CPU 1 is 
connected to the RAM 2, the device 3 and the non-volatile 
memory 4 through the bus 5, which leads to a condition that they 
30 can be communicated with each other. Also, the bus 5 may be a 
network. 

The control of initialization of a component provided for 
each function of the present invention will be described below 
with reference to a flowchart shown in Fig. 2. At a step SI, 
35 when a component provided for each function (hereafter, 
referred to simply as a component) such as an application, a 
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device, a driver or the like is activated, an internal variable 
thereof is initialized. At step S2, a dependency relation 
between the components is recorded in a status-storing database 
by the component itself. At a time of a system status-storing 
5 processing as described later, the component recorded in this 
status-storing database is regarded as a target fbr the 
status-storing operation. In this way, the flowchart shown in 
Fig. 2 shows an initialization operation at a time of booting of an 
application, a device driver or the like. 
; 10 A system status-storing process will be described below 

with reference to Fig. 3. Fig. 3 shows the relation between 
modules to be executed by the CPU 1, which exist on a memory 
O _ that can be accessed by the CPU 1. A request for the 
S status-storing process is outputted from a certain application 
W15 among applications 14 to a check point manager 12 in this 
JiS module 11. A request for an execution of a snap shot output to 
fy the component, such as the application 14, a device driver 15 
and the like, is outputted to the check point manager 12. An 
U order or sequence in which this request is outputted is based on a 
f^20' sequence recorded in a status-storing database 13 in this module 
m . 11. The sequence recorded in this status-storing database 13 
y represents the dependence relation between the components. 

When each component receives the request for the snap 
shot output, a function existing in a particular address for each 
25 component is read out and the component status is outputted as a 
snap shot data through the check point manager 12 to a 
non-volatile memory driver 16. When the output of the snap 
shot data for each component is ended, all the output snap shot 
data are used as snap shot files shown in Figs. 4A, 4B, and the 
30 non-volatile memory driver 16 stores them in a recording 
medium (not shown). The non-volatile memory driver 16 
supports an operation for writing to and reading from various 
recording media, for example, a non-volatile memory card. 
Then, the process returns back to the application 14 outputting 
35 the request for the status-storing process. 

A tag of a component name (character string) shown in 



5 



Figs. 4A, 4B is given to the snap shot file, which is stored in the 
recording medium by the non-volatile memory driver 16, for 
example, as a combination of an index file and a data file. Fig. 
4A shows an example of a format of the index file, and Fig. 4B 
shows an example of a format of the data file. As shown in Fig. 
4A, the index file stores therein a component name, and an offset 
position in a data file of a data corresponding to the component 
name. As shown in Fig. 4B, the snap shot data outputted by 
each component is stored in the data file, in connection with one 
file. 

As mentioned above, the status-storing process of the 
system is activated (booted) at arbitrary timing during the 
execution of the application or for each cycle specified by the 
system or the application. Once the status-storing process is 
activated, a next request for the status-storing process is kept 
until an end of that process. 

The snap shot file to be recorded in the recording medium 
by the non-volatile memory driver 16 is recorded in accordance 
with the sequence recorded in the status-storing database 13. 
Thus, the dependency relation between the components is 
reflected. 

It will be described below with reference to a flowchart of 
an example of the status-storing process of the system in Fig. 5. 
At a step Sll, the snap shot file is initialized. At a step S12, 
the status-storing database 13 is opened. At a step S13, it is 
judged whether or not the component targeted for the status 
storing operation exists or is available. In accordance with the 
sequence recorded in the status-storing database 13, if it is 
judged that the component targeted for the status storing 
operation still exists, the control proceeds to a step S14. If it is 
judged that the component targeted for the status storing 
operation does not exist, the control proceeds to a step S16. 

At step S14, the index data is outputted from the 
component targeted for the status storing operation through the 
check point manager 12 to the non-volatile memory driver 16. 
At a step S15, the snap shot data is outputted from the 



component targeted for the status storing operation through the 
check point manager 12 to the non-volatile memory driver 16. 

At a step S16, the snap shot file stored in the recording 
medium by the non-volatile memory driver 16 is closed. At a 
5 step S17, the status-storing database 13 is closed. 

A system status recovering process will be described 
below with reference to Fig. 6. Fig. 6 shows a relation between 
the modules to be executed by the CPU 1, which exist on the 
memory that can be accessed by the CPU 1. A booting unit 17 
; 10 of the system outputs a request for the status recovering process 
to the check point manager 12. In accordance with this request 
for the status recovering process, the check point manager 12 
D ^ requests the non-volatile memory driver 16 to read the snap shot 
Jj file. As mentioned above, the dependency relation between the 
i|l5 components are reflected in the snap shot file. The check point 
*S manager 12 retrieves a component of an application device 
III driver 18 having its status recovered, from the component name 
y stored in the snap shot file, and firstly reads the component as 
u necessary, and carries out booting. 

H20 Then, an address of a function to be called from a symbol 

yg information held by the component is obtained through the 
H non-volatile memory driver 16 from the recording medium, and 
the function is called from the address. The function to be 
called exists for each component in a particular address. Those 
25 processes are executed for all the components stored in the snap 
shot file. By the way, at this time, the dependency relation 
between the components is recorded in the status-storing 
database 13 within this module 11 by the component itself. The 
content recorded in this status-storing database 13 is accessed at 
30 the time of a further request for the status-storing process. 

By the way, the status recovering process can be carried 
out not only at the time of the booting of the system but also an 
arbitrary timing. However, once the status recovering process 
is activated, a next request for the status recovering process is 
35 kept standing by until an end of the previous status recovering 
process. 
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An example of the system status recovering process will 
be described below with reference to a flowchart of Fig. 7. At 
a step S21, the snap shot file stored in the recording medium by 
the non-volatile memory driver 16 is opened. At a step S22, the 
5 status-storing database 13 is opened. At a step S23, the index 
data stored in the recording medium by the non-volatile memory 
driver 16 is read in. At a step S24, it is judged whether or not 
the component that needs to be read is ended, in accordance with 
the stored index data. If it is judged in accordance with the 

io index data that the component that needs to be read is not still 
ended, the control proceeds to a step S25. If it is judged that 
all the components that need to be read are ended, the control 

g proceeds to a step S29. 

iJ 3 At step S25, the stored snap shot data is read from the 

& recording medium through the non-volatile memory driver 16. 
W At a step S26, the component is read in accordance with the read 
m in snap shot data, and it is activated. At a step S27, the status 
O recovering process is carried out. Actually, the address of the 
te function to be read out is obtained from the symbol information 
i#o held by the component. Then, the function is called from the 
;J address. The function to be called exists for each component in 
O a particular address. At a step S28, the component itself and 
the dependency relation between components are recorded in the 
status-storing database 13 within this module 11 by the 
25 component itself. Then, the control returns back to the step 
S23. 

At a step S29, the snap shot file stored in the recording 
medium by the non-volatile memory driver 16 is closed. At a 
step S30, the status-storing database 13 is closed. 

30 In this preferred embodiment of the invention, even if the 

application operates on the system, the status-storing operation 
can be executed in the background without an operator operating 
the system taking notice of such operation. 

This preferred embodiment of the present invention can be 

35 applied to any apparatus if it has the configuration shown in Fig. 
1. For example, this embodiment can be applied to a portable 



telephone, PDA (Personal Digital Assistant), a notebook PC or 
the like. 

In the preferred embodiment present here, if the recording 
medium in which the snap shot file is stored by the non-volatile 
5 memory driver 16, for example, an IC card is inserted into a PC 
different from a PC in which the snap shot file is stored, and the 
status recovering process is then carried out, the PC into which 
the IC card is inserted can be used in an environment completely 
equivalent to that of the PC in which the snap shot file is stored. 

10 According to the preferred embodiments of present 

invention, it is possible to carry out booting of a device in 
accordance with the dependency relation of the device, when the 

O power supply is again turned on, and it is further possible to 

•|r recover the original status at a high speed. 

m Moreover, according to the preferred embodiments present 

^ invention, the data required to recover a status of a certain 
•5] component is shunted or recovered by the component itself. 
O Thus, recovering can be attained at a minimum necessary small 
^ amount of data. 

2» Also, according to the preferred embodiments of the 

J present invention, as the information for the recovery is stored in 
Q a portable memory device, if the memory device is connected to 
^ another apparatus, the status can be recovered at a high speed. 

Moreover, according to the present invention, the status 
25 can be recovered not only at the time of the booting of the 
system but also an arbitrary timing. 

Although the present invention been described in its 
preferred form with a certain degree of particularity, obviously 
many changes, variations, combinations and sub-combinations 
30 are possible therein. It is therefore to be understood that any 
modifications will be practiced otherwise than as specifically 
described herein without departing from the scope of the present 
invention. 
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